DevSecOps_02_로컬 기반 보안 분석 도구 생각해보기

보안 도구를 도입할 때 가장 먼저 고민해야 할 것은 "어디서 실행할 것인가?"이다. 일반적으로 중앙 집중형 서버(Server-Client) 모델이 널리 쓰이지만, DevSecOps의 철학인 '개발자 주도 보안'을 실현하기 위해서는 로컬 독립형(Standalone) 모델도 대안이 될 수 있다. 두 아키텍처의 트레이드오프를 분석하고, 로컬 기반 설계가 유효할지 생각해봤다.

1. 중앙 집중형 vs 로컬 독립형

대부분의 상용 SAST 도구(SonarQube 등)는 중앙 서버 모델을 채택한다. 개발자가 코드를 커밋하면, CI 서버가 이를 감지하여 분석 서버로 코드를 전송하고, 분석가들이 대시보드에서 결과를 확인하는 구조다.

1.1. 중앙 집중형 모델의 한계

관리자 입장에서는 중앙 통제가 용이하다는 장점이 있지만, 개발자 입장에서는 다음과 같은 마찰(Friction)이 발생한다.

• 피드백 지연(Latency): 코드를 올리고 분석 결과가 나올 때까지 기다려야 한다. 흐름이 끊긴다.
• 인프라 종속성: 분석 서버가 죽으면 배포도 막힌다.
• 코드 외부 유출: 민감한 소스 코드를 외부 분석 서버로 전송해야 하는 보안 리스크가 존재한다.

1.2. 로컬 독립형 모델의 강점

반면, 보안 도구를 컴파일러처럼 로컬 PC에서 실행 가능한 형태로 배포하는 모델이다.

• 즉각적인 피드백: 네트워크 통신 없이 내 컴퓨터에서 pre-push 단계에 검사하므로 속도가 매우 빠르다.
• 오프라인 동작: 인터넷이 없는 폐쇄망 환경에서도 동작 가능하다.
• Zero-Trust: 소스 코드가 개발자 PC 밖으로 나가지 않는다.

2. 로컬 분석 도구의 아키텍처 설계

나는 rootscan 프로젝트를 구상하면서 이러한 로컬 독립형 모델을 기반으로 설계하였다. 무거운 분석 엔진을 서버에 두는 대신, 경량화된 오픈소스 엔진을 래핑(Wrapping)하여 개발자 환경에 배포한다.

2.1. 엔진 레이어(Engine Layer)

바퀴를 다시 발명할 필요는 없다. 검증된 오픈소스 도구를 엔진으로 활용한다.

• Semgrep: 속도가 빠르고 Python 커스텀 룰 작성이 용이하여 SAST 엔진으로 채택.
• Trivy: 취약점 데이터베이스(CVE)가 로컬 DB 파일로 제공되어 오프라인 스캔에 유리.

2.2. 인터페이스 레이어(Interface Layer)

엔진이 뱉어내는 날것(Raw)의 로그는 개발자가 읽기 힘들다. 이를 추상화하는 레이어가 필요하다.

• CLI: 복잡한 옵션 없이 scan 명령어 하나로 동작하도록 단순화.
• Unified Reporter: 각기 다른 엔진(JSON 등)의 출력 포맷을 통일된 Markdown 리포트로 변환.

3. Git Hook과의 결합 논리

이 아키텍처의 중요한 부분은 Git Hook이다. 아무리 좋은 도구도 실행하지 않으면 무용지물이다. 개발자가 의식적으로 도구를 실행하게 만드는 것은 실패할 확률이 높다.

개발자의 습관(Routine) 속에 도구를 숨겨야 한다고 생각했다. git push 명령어 실행 시 훅이 트리거되어 분석을 수행하고, 임계치(Threshold) 이상의 취약점이 발견되면 Push 자체를 차단(Reject)한다. 이는 보안이 '선택'이 아닌 '필수 절차'로 자연스럽게 스며들게 하는 아키텍처적 장치다.